Data processing method, system and computer program

ABSTRACT

A system, method and computer program product are disclosed for data processing in a supply chain management utilizing a central data processing system which integrates a plurality of functionalities for partner and system determination, as well as availability checking. Upon receiving a request which includes a plurality of items from a customer, unique identifiers are generated and assigned relevant to the customer&#39;s items in response to the request. Each request is split into plurality of sub-requests where each sub-request is assigned to an internal or external system by means of the rules. In case a synchronous communication is used the dynamic combining of the sub-results is performed at runtime. In case an asynchronous communication is employed, the sub-responses are aggregated in a database until all sub-responses have been received. The amount of requested resources is adjusted in both cases based on the information received from the central data processing system.

FIELD OF THE INVENTION

The present invention relates in general to a data processing systemand, in particular, to a supply chain management system and method.

BACKGROUND AND PRIOR ART

The modern logistic network of the business relationships has evolvedinto increasingly complex multi-partner and multi-system environmentshaped by dynamic events. Supply chain management is getting moreunpredictable for example due to outsourcing or globalization. Thedetermination of a partner in the modern supply chain is usually done byfunctionalities located in vast array of systems: for example, planningsystems, purchasing systems, and transportation systems. Many of thesesystems are often legacy systems. Thus, the coordination of processesinside the logistic network needs to be responsive, adaptive and open tointegrate partners.

U.S. Pat. No. 6,591,243 (Grettve et al.) discloses a method and systemfor improved supply chain management where detailed description of theprior art logistic systems and the related prior art problems areincluded.

One of the considerable problems plaguing Supply Chain Management is thelack of timely communication between the different partners and systemsin the supply chain what in turn results in higher costs, inadequateresources or even waste. Also, the lack of possibility to quickly andeffectively determine at run time which partners or systems areavailable adds to the problem. Therefore, there is a need for centraldata processing system that would be flexible and able to react todifferent business scenarios.

SUMMARY OF THE INVENTION

According to various embodiments of the central data processing systemdisclosed herein, a method which integrates a plurality offunctionalities for partner and system determination, as well asavailability checking is described. The central data processing systemincludes hardware, software and communications components thatcooperatively achieve the technical effect of an improved, centralizeddata processing in a supply chain management. A customer requestcontaining plurality of items is received from a corresponding customerof a supply chain. Item unique identifiers are generated and assigned tothe items. Then, a plurality of sub-requests is generated where eachsub-request is assigned to a system by means of the rules.

The sub-requests carrying separate unique identifiers are processed atthe partner side and sub-responses are received at the central dataprocessing system. Responses are generated based on association ofsub-responses with the same original item and then, send back to thecustomers data processing system. In case the synchronous communicationis used the dynamic combining of the sub-results is performed atruntime. In case asynchronous communication is employed, thesub-responses are aggregated in a database until all sub-responses havebeen received. The amount of requested resources is adjusted in bothcases based on the information received from the central data processingsystem.

The present invention makes possible to easily plug in the existingfunctionalities into the one central data processing system which couldprovide flexible and adaptable partner and system determination, as wellas, availability checks in a supply chain management. It also enablesfaster and more effective execution and control of logistic processes ina complex partner/system environment. It also provides an interface thatallows a customer to deal with one system and avoid the complexity ofmultiple systems and functions.

In another aspect, the present invention relates to a data processingsystem for processing a request. Typically, the request comprises anumber of request items. For example, the request can be a costumerquery regarding the availability and delivery conditions for the itemsas listed in the request. The data processing system is coupled to anumber of partner computer systems. The data processing system selectsan asynchronous or a synchronous communication mode for communicationwith the partner computer systems in order to process the request. Thedetermination whether asynchronous or synchronous communication is to beselected can be made using a set of rules that are applied on therequest. This rulebase can also be used in order to split the requestinto a set of sub-requests where each sub-request is assigned to one ofthe partner computer systems. If the synchronous communication mode hasbeen selected with respect to one of the partner computer systems thesub-requests are sent sequentially from the data processing system tothe respective partner computer systems. In other words, a consecutivesub-request is only sent from the data processing system to one of thepartner computer systems if a response to a previous sub-request hasbeen received by the data processing system. The sub-responses of thepartner computer systems are held in the main memory of the dataprocessing system, i.e. a random access memory. After all sub-responseshave been received, the sub-responses are combined into a consolidatedresponse that is sent back to the requester, e.g. the sales system.

If the asynchronous communication mode has been selected some or all ofthe sub-requests can be sent in parallel to the respective partnercomputer systems. Each time a sub-response is received from the partnercomputer systems, the status of a database is checked. The database isstored on a non-volatile storage device, such as a magnetic disc. If thestatus of the database indicates that all sub-responses except the newlyreceived sub-response are already present in the database, thesub-responses are read out from the database and are combined into aconsolidated response which is then sent back to the requestor.

For example, a unique identifier, such as a globally unique identifier(GUID), is assigned to the sub-requests. The sub-request that is sent toa partner computer system carries its unique identifier. Thesub-response received from the partner computer system in response tothe respective sub-request carries the same unique identifier. Theunique identifiers are used as database keys for storing thesub-responses in the database and for determining the status of thedatabase by querying the database by means of the unique identifiers.

The present invention is particularly advantageous as it enables thedata processing system to communicate both in an asynchronous or asynchronous communication mode with the partner computer systems thatare coupled to the central data processing system. The synchronouscommunication mode has the advantage that a response can be provided tothe requestor with a minimal latency time, as no storage operations onthe non-volatile storage device and no database queries are required asthe respective information is held in the random access memory. However,the synchronous communication mode does not allow to send a number ofthe sub-requests in parallel to the partner computer systems. Asparallelization of the processing is not possible this results inrelatively long idle times for the data processing system where the dataprocessing system is in a wait state in order to wait for a sub-responseuntil the next sub-request can be sent out to the respective partnercomputer system.

The asynchronous communication mode has the advantage that a number ofsub-requests can be sent out in parallel to the partner computersystems. Because of the storage of the sub-responses in the database andthe query operations that are required in order to determine whether allsub-responses have already been received a longer latency time istypically experienced in the asynchronous communication mode forproviding the response. However, the parallelization of the processingsubstantially reduces the idle times of the central data processingsystem and thus enables to maximize the overall system throughput inorder to make maximum usage of the available hardware resources.

It is thus possible to select the synchronous or asynchronouscommunication modes depending on the requestor's preferences which canbe given in the request and/or depending on the partner computersystem's communication capabilities. For example, some of the partnercomputer systems are capable to communicate in only one of theasynchronous or synchronous communication modes whereas other partnercomputer systems have the capability to communicate both in theasynchronous and synchronous communication modes. These capabilities ofthe partner computer systems and/or user preferences can be stored asrules in the central data processing system for selecting theasynchronous or synchronous communication modes.

In particular the present invention can be used for a fulfillmentcoordination engine as described in PCT Patent Application WO 03/075195A2 which is herein incorporated by reference in its entirety.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a central data processing system for processing ofthe customer request of the present invention.

FIG. 2 is a flowchart of a process describing a method of the presentinvention.

FIG. 3A illustrates structure of the document used in a central dataprocessing system and mapping of the data from standard orders.

FIG. 3B illustrates the case when base documents used in a central dataprocessing system create document hierarchies.

FIG. 4 is a block diagram of a more detailed embodiment of the centraldata processing system of the present invention where synchronouscommunication is used.

FIG. 5 is a block diagram of a more detailed embodiment of the centraldata processing system of the present invention where asynchronouscommunication is used.

FIG. 6 is a block diagram of a further preferred embodiment of a dataprocessing system of the invention,

FIG. 7 is a flow diagram illustrating a preferred mode of operation ofthe data processing system of FIG. 6.

DETAILED DESCRIPTION

The claimed invention is applicable to many different industries. Oneskilled in the art will appreciate that the various embodiments andconcepts of the present invention are applicable to plurality ofindustries without straying from the spirit of the present invention.

The present invention includes a supply chain management systeminvolving at least one customer. Supply chain also includes at least onepartner. The supply chain partners include business partners, locationsand logical systems.

Exchange Infrastructure (XI) can be used for various embodiments of thepresent invention. It enables the development of the cross-systemapplications that exchange a multitude of system messages using theruntime infrastructure and synchronous or asynchronous communication.However, since the use of synchronous communication via the XI currentlyrequires that the called function works without state, the partnerascertainment service can only be called synchronously via the XI if theapplication scenario does not require that the partner ascertainmentservice or any of the partner ascertainment functions it calls work withstate.

The aim of the Exchange Infrastructure is to integrate different systemsimplemented on different platforms (Java, ABAP, and so on). The ExchangeInfrastructure is based on an open architecture, makes uses of openstandards, in particular those from the XML (eXtensible Markup Language)and Java environments; and offers services that are essential in aheterogeneous and complex system landscape: namely a runtimeinfrastructure for message exchange; configuration options for managingbusiness processes and message flow; and options for transformingmessage contents between the sender and receiver systems.

FIG. 1 illustrates a central data processing system 108 for processingof a customer request 114 according to an embodiment of the presentinvention. Sales system 104 provides electronic connectivity to thecentral data processing system and enables collection of customerrequests for future processing. Utilizing a network, for example anInternet 102, a request for at least one item is received from acorresponding customer 100 at the central data processing system.

Subsequently, a central data processing system checks if each item has aunique identifier 106; if an item is found without a unique identifier,a new unique identifier 116 is generated and assigned to this item.Customer requests comprising a plurality of items are then processed bymeans of a set of rules 118 in a looping mode, that is when the requesthas more then one item then each item is sequentially processed and theresponse is send for each item.

The control program 110 implements the corresponding control processes.The assigned unique identifiers are then stored in a database 112. Whenpartner systems such as for example a purchasing system 120, amanufacturing system 122, a planning system 124 or any other internal orexternal systems 126 send their responses back, those responses areassociated in turn with the original items and the final response isthen sent to the customer's data processing system.

FIG. 2 depicts a corresponding flow chart. In the step 200 a request forat least one item is sent by the customer's data processing system, inthis case a Sales system. When request is received in a central dataprocessing system, in this case a Fulfilment Coordination Engine (FCE),in the step 202 each item is checked for presence of the uniqueidentifier; if the unique identifier is missing the FCE generates andassigns unique identifiers to the item. Then, in the step 204, thesub-requests are generated and assigned to a partner's system by meansof the rules.

In the next step 206 each of the sub-requests receives a separate uniqueidentifier and assigned unique identifiers are stored in the retrievablemedium in the step 208. That means that in case of asynchronouscommunication, the unique identifiers are stored in the database.However, in the case of synchronous communication the unique identifiersare stored in the memory and they are only in this case stored in thedatabase when the Logical Unit of Work (LUW) in the called system isended with the command COMMIT. In the step 210 sub-requests are sent topartner systems.

At the partner system side steps 212 and 214 are performed. First, allthe requests are processed and then sub-responses including uniqueidentifiers and information are send back to the central data processingsystem. Fulfilment Coordination Engine, in the step 216, receives allsub-responses from the partner systems and in the step 218, theresponses are generated based on association of sub-responses with theoriginal item. In the final step 220, the responses are send back to thecustomer's data processing system, in this case a sales system.

FIG. 3A illustrates a structure of the document used in the central dataprocessing system and associated mapping of the data from standardorders. Data processing conducted in multi-system and multi-businessenvironment means that various document types can be used such as forexample purchase orders or sales orders.

In order to be able to operate on the plurality of documents, centraldata processing system can for example use an order-like documentstructure 326 that consists of a header section 328, at least one item330 that can contain for example fields like business partner, product,location or contract; and at least one schedule line 332 per itemcomprising information regarding a delivery date and a quantity. Thisspecial design of the three level structure allows all documents thatexist in internal systems as well as all those documents of differentapplications that are relevant for central data processing to be mapped.If for example, sales order processing calls the central data processingsystem, then the data of the sales order 334 that was transferred to thecentral data processing system via the interface, is mapped onto thedocument 326.

The sales order header 335 is mapped on the document header 328, theorder items 336 are mapped on the document items 330 and the requestschedule lines 337 on the document schedule lines 332. The similarprocess takes place when the system receives a purchase order 344. Thepurchase order header 345 is mapped on the document header 328, thepurchase order items 346 are mapped on the document items 330 and thepurchase order schedule lines 347 on the document schedule lines 332.

FIG. 3B depicts, for example, the case when product substitution and/orlocation substitution occurs and base documents 350 create documenthierarchies. For example in the result 358, schedule lines 354 have alist of successor items 352 which can include partners, substitutionproducts or locations. Also, a schedule line 354 contains severalsuccessor documents 356. Beside product and/or location substitutionalso further hierarchy levels can be produced in the document.

FIG. 4 illustrates a more detailed embodiment of the data processingsystem of the present invention, describing a case when synchronouscommunication is used throughout the supply chain. The embodiment ofFIG. 4 constitutes a logical continuation of the FIG. 1 where likeelements are referenced by like reference numbers having added 300.Synchronous communication takes place in this embodiment of theinvention via Synchronous Remote Function Call (sRFC) 413 if any of thecalled partner functions work with state. Since the use of synchronouscommunication via the XI currently requires that the called functionworks without state, the partner ascertainment service can only becalled synchronously via the XI if the application scenario does notrequire that the partner ascertainment service or any of the partner'sfunctions it calls work with state.

According with the preferred embodiment the central data processingsystem is in this case a Fulfilment Coordination Engine (FCE) 408. Asshown in FIG. 4, FCE receives a request 414 for at least one item from acorresponding customer 400 via the Network 409 which can also includeInternet 402. In this case a calling application is a Sales system 404.Subsequently, each item is checked for the presence of a uniqueidentifier 406, if an item is found without a unique identifier, a newunique identifier 416 is generated and assigned to this item. Thecontrol program 410 is the central component of the FulfilmentCoordination Engine.

The control program must be called to begin the request processing. Theset of rules 418 determined by the control program contains a sortprofile, a selection profile, a search key and the determinationprocedure. A sort profile is used to determine how partner lists shouldbe sorted for further processing. A selection profile is used to definethe procedure used to select partners. A search key and thedetermination procedure are used to determine whether an availabilitycheck is executed and if so, what kind. A plurality of sub-requests 430for plurality of partners' systems is then generated where eachsub-request is assigned to an internal or external system by means ofthe set of rules where complex dependencies have access using ConditionTechnology 427. In this case, the objects, for example rules searchedfor are determined by evaluating conditions. The search key is theninterpreted as a condition type.

The Fulfilment Coordination Engine then calls synchronously functions417 according to Customizing 425. When synchronous communication isused, the customer receives immediately a response also synchronously,so that customer's data processing system can continue working. In mostcases, called functions are implemented in the external systems.Functions are not called directly but via corresponding interfaces 415.In contrast to functions, the interfaces are always implemented on theside of the central data processing system. The call of a function, andthe respective mapping are implemented within an interface. There is a1:1 relationship between interfaces and functions: There must be aseparate interface for each of the functions. In contrast, an N: Mrelationship exists between interfaces and logical systems.

The assigned unique identifiers are then stored in a database 412 whilesub-requests are sent to different partner systems. Sending of thesub-requests to partner systems such as for example a purchasing system420, a manufacturing system 422, a planning system 424 or any otherinternal or external systems 426 further comprises either sending arequest for a partner search or a partner availability check atschedule-line level or determining at least one business system or anavailability check for this system at schedule-line level. It is furtherdetermined on the item level which availability check function should becalled. A separate unique identifier for each of the sub-requests isthen generated.

Availability check returns confirmation of dates and quantities as wellas, if necessary, alternative products and/or locations are included.The availability check reserves temporary a requested resources thathave been identified as available. The resources are reserved this waythat the requested resources are equal to the original resources lessthe quantities that have already been confirmed and reserved viapartner's system functions previously called. Thus, availability checkscarried out in processes running in parallel do not consume the samequantities. It is assured that overbooking of resources does not occurduring an availability check.

Some functions enable the assignment of an expiration date to theirtemporary quantity assignments. If this date has been reached, thetemporary quantity assignments are automatically handled (deleted, forexample). Up to this date, the temporary quantity assignments areactive, that is, they reserve a quantity. However, if the expirationdate is not assigned automatically, the Fulfilment Coordination Enginehas to sent a specific message terminating the reservation of resources.

On the other hand, when partner search is executed, a list of partnersis returned. Subject to the partner's functions used, further data suchas prices and contracts, and similar, can be also included.

Supply Chain Management (SCM) scheduling module 428 can be called by theFulfilment Coordination Engine to determine the dates which aretransferred to the partners' functions based on the dates received fromthe customer. Also, it is further used to determine the dates to bereturned to the customer based on the dates received in thesub-responses from the partners' systems.

When Fulfilment Coordination Engine receives the sub-responses 432,those resulting sub-responses which are sent by the partner systems backto the FCE have the same unique identifiers as the sub-requests sentoriginally. Thus, the sub-responses can be associated on the base of thematched unique identifiers with the original sub-requests. Thosesub-responses are then stored in the main memory 411 of the FulfilmentCoordination Engine and the internal logic checks if all the roots ofthe unique identifiers are there so the final response 434 can be sentto the customer's data processing system immediately in order for it tocontinue working without interruptions. The response can be displayedutilizing a sales system interface 407. However, it is also possiblethat the result is not displayed at all, it depends on the callingsystem/application which of the two options occurs. In any case, all thedetails of the partner search or/and availability check are hidden fromthe calling system/application.

FIG. 5 illustrates a more detailed embodiment of the data processingsystem of the present invention, describing a case when an asynchronouscommunication is used throughout the supply chain. The embodiment ofFIG. 5 constitutes a logical continuation of the FIG. 1 where likeelements are referenced by like reference numbers having added 400.

According with the preferred embodiment the central data processingsystem is in this case a Fulfilment Coordination Engine (FCE) 508. Inthe case of the use of asynchronous communication the FulfilmentCoordination Engine is called asynchronously and it also callsasynchronously the functions located in the external partner systems(520, 522, 524, and 526) via the control program. Asynchronouscommunication takes place via the Exchange Infrastructure (XI) 513.

Thus, the Fulfilment Coordination Engine 508 receives asynchronously arequest 514 for at least one item from a corresponding customer 500 viathe Network 509. In this case an asynchronous call is made by salessystem 504. Subsequently, each item is checked for the presence of aunique identifier 506, if an item is found without a unique identifier,a new unique identifier 516 is generated and assigned to this item. Aplurality of sub-requests 530 for plurality of partners' systems is thengenerated where each sub-request is assigned to an internal or externalsystem by means of the set of rules 518 which allow to configure thesequence functions are called. Complex dependencies have access usingCondition Technology 527. Then the Fulfilment Coordination Engine callsasynchronously partner's functions according to Customizing 525 via thecontrol program 510 and the sub-requests are processed at the partnerside. The resulting sub-responses which are sent by the partner systemsback to the Fulfilment Coordination Engine have the same uniqueidentifiers as the sub-requests sent originally.

Thus, when FCE receives asynchronously the sub-responses 532, thosesub-responses are stored in the database tables 511 and can beassociated on the base of the matched unique identifiers with theoriginal sub-requests, so that the central data processing can becontinued when all the sub-responses of the asynchronous function callsare available. In order to determine if all sub-responses are collected,a control program 510 performs a query each time a sub-response comesback from the partner system, in order to retrieve all relevantsub-responses stored so far in the database.

If the number of the stored responses is determined to be insufficient,the received sub-response is then stored in the database until all thesub-responses are collected. When on the other hand, the database querydetermines all the received sub-responses to be sufficient, then thefinal response 534 is sent to the customer's data processing system. Theresponse can be displayed utilizing a sales system interface 507.However, it is also possible that the result is not displayed at all, itdepends on the calling system/application which of the two optionsoccurs. In any case, all the details of the partner search or/andavailability check are hidden from the calling system/application.

SCM scheduling module 528 can be called by the Fulfilment CoordinationEngine system to determine the dates which are transferred to thepartners' functions based on the dates received from the customer. Also,it is further used to determine the dates to be returned to the customerbased on the dates received in the sub-responses from the partners'systems.

In case of asynchronous communication, also the workflow 529 can be usedtogether with the Fulfilment Coordination Engine. In this casesub-responses from partner's functions are received via the workflowwhich is started when asynchronous calls of the partner's functions aretriggered.

FIG. 6 shows a block diagram of an alternative embodiment of the centraldata processing system. Elements of the embodiment of FIG. 6 thatcorrespond to elements of the embodiments of FIG. 1, 4 or 5 aredesignated by like reference numerals.

The central data processing system 608 has a control program 610 that isexecuted by a processor of the central data processing system 608 (notshown in the drawing). The control program 610 controls operation of thecentral data processing system 608. Further, the central data processingsystem 608 has a rules module 618 for storage of rules that are used forselecting the asynchronous or synchronous communication mode and forsplitting a request 614 into sub-requests 630. The central dataprocessing system 608 has one or more interfaces 619, such as TCP/IPcapable interfaces, for receiving the customer request 614, sending aresponse to the customer request back to the requestor and forcommunicating with the partner computer systems (not shown in FIG. 6)that are coupled to the central data processing system 608.

The central data processing system 608 has a non-volatile storagemedium, such as a magnetic disc, for storing a database 612. In additionthe central data processing system 608 has a main memory 613, i.e. arandom access memory. Depending on the selected communication modesub-responses received from the partner computer systems are stored inthe database 612 or in the main memory 613. After all sub-responses fora request 614 have been received a respective response that combines thesub-responses is generated and sent back to the requestor from thecentral data processing system 608.

In operation the central data processing system 608 receives the request614. In the example considered here, the request 614 carries a number ofitems A, B, C . . . that identify respective products or services thatthe customer considers to purchase or order. When the central dataprocessing system 608 receives the request 614 the control program 610is invoked and applies the rules of rules module 618 to the customerrequest in order to select the synchronous or asynchronous communicationmode and in order to split the request 614 into sub-requests, ifnecessary. In addition, individual items contained in the request 614can be split into sub-items, if required by the rules. Each item,sub-item and sub-request get assigned a unique identifier (ID) such as aglobally unique identifier.

If the synchronous communication mode is selected, data 670 is stored inthe main memory 613. The data 670 describes the mapping of item IDs tosub-item IDs. Likewise data 672 that describes the mapping ofsub-requests to item and sub-item IDs is stored in the main memory 613.

When one of the sub-requests 630 is sent from the central dataprocessing system 608 to the respective partner computer system, thecentral data processing system 608 receives a sub-response 632. Both thesub-request 630 and the sub-response 632 carry the same sub-request IDthat enables the central data processing system 608 to interpretsub-response 632 as belonging to the sub-request 630. In the synchronouscommunication mode the sub-responses 632 that are received from thepartner computer systems are stored in the main memory 613.

In the asynchronous communication mode the data 670 and data 672 isstored on a non-volatile storage medium. The sub-responses 632 arestored in the database 612 using the respecting sub-request IDs asdatabase keys.

In the synchronous communication mode the central data processing system608 sends one of the sub-requests 630 of request 614 at a time to therespective partner computer system. The central data processing system608 waits for the sub-response 632 until the next sub-request 630 issent out. When all sub-responses 632 have been received and temporarilystored in the main memory 613 the sub-responses 632 are combined by thecontrol program 610 in order generate a response that is sent back tothe requestor by means of interface 619.

In the asynchronous communication mode a plurality of the sub-requests630 can be sent out to the respective partner computer systems inparallel. Each time a sub-response 632 is received from one of thepartner computer systems the status of the database 612 is checked forcompleteness of the sub-responses 632. This can be done by querying thedatabase 612 using the sub-request IDs of the sub-responses as a querycriterion. If all sub-responses 632 for a given request 614 except thenewly received sub-response 632 are already stored in the database 612the sub-responses 632 are read from the database 612 into the mainmemory 613 for generating the response to the requester.

FIG. 7 shows a corresponding flowchart.

In step 700 a customer request is received by the central dataprocessing system. In step 702 a set of rules is applied to the requestin order to determine whether synchronous or asynchronous communicationis to be used. In addition the request is split up into a number J ofsub-requests j if required (step 704 in the case of synchronouscommunication and step 706 in the step of asynchronous communication).

In the synchronous communication mode the index j is initialized in step708. In step 710 the first sub-request j is sent from the central dataprocessing system to the respective partner computer system. The centraldata processing system is in a wait state until it receives thesub-response j from the partner computer system in step 712. Thesub-response j is stored in the random access memory of the central dataprocessing system. In step 714 the index j is incremented and thecontrol goes back to step 710.

After all sub-responses j for the request have been received the controlgoes to step 716 where the sub-responses that are temporarily stored inthe random access memory are combined in order to generate the responseto the request received in step 700 (step 716). The response is sentback to the requestor in step 718.

If the asynchronous communication mode has been selected in step 702 theunique identifiers that are assigned to the sub-requests are used askeys for storage of the sub-requests in the database (step 706). In step720 the sub-requests are sent to the partner computer systems. This canbe done in parallel. In step 722 a sub-response is received from one ofthe partner computer systems. The sub-response carries the same uniqueID as its respective sub-request. This enables the central dataprocessing system to identify the sub-response as belonging to one ofthe sub-requests that have been sent out in step 720. In step 724 thecentral data processing system checks the status of the database. If allsub-responses have already been received the previously receivedsub-responses are read from the database in step 726 and the response isgenerated in step 728 before it is sent out in step 718.

If the contrary is the case, the sub-response received in step 722 isstored in the database using its unique ID as a key (step 730). Fromthere the control goes back to step 722. The status check in step 724 isperformed each time a sub-response is received from one of the partnercomputer systems in order to determine, whether all sub-responses havealready been received or not.

Although the present invention has been described in detail withreference to certain preferred versions thereof, other versions arepossible. The detailed descriptions of the synchronous and asynchronouscommunication in FIGS. 4 and 5 were presented as unmixed systems for thesake of the clarity.

Nevertheless, the present invention is also designed for the manyversions of mixed asynchronous and synchronous communication. Forexample, the calling system/application can send a synchronous call,then the Fulfilment Coordination Engine can call some of the partnersystems using synchronous communication and other systems can be calledasynchronously. Also, other variations of mixed systems are possible.Therefore the spirit and scope of the appended claims should not belimited to the preferred versions herein.

LIST OF REFERENCE NUMERALS

-   -   100 customer    -   102 internet    -   104 sales system    -   106 unique identifier    -   108 central data processing system    -   110 control program    -   112 database    -   114 request    -   116 unique identifier    -   118 rules module    -   120 purchasing system    -   122 manufacturing system    -   124 planning system    -   126 other internal or external system    -   326 document of the central data processing system    -   328 document header    -   330 document items    -   332 document schedule lines    -   334 sales order    -   335 sales order header    -   336 sales order items    -   337 sales order schedule lines    -   344 purchase order    -   345 purchase order header    -   346 purchase order items    -   347 purchase order schedule lines    -   350 base document    -   352 item    -   354 schedule line    -   356 successor document    -   358 result    -   400 customer    -   402 internet    -   404 sales system    -   406 unique Identifier    -   407 interface    -   408 Fulfilment Coordination Engine    -   409 network    -   410 control program    -   411 memory used for storage of sub-responses    -   412 database used for storage of the unique identifiers    -   413 Synchronous Remote Function Call    -   414 request    -   415 interface    -   416 unique identifier    -   417 functions    -   418 rules module    -   420 purchasing system    -   422 manufacturing system    -   424 planning system    -   425 customizing and core data module    -   426 other internal or external system    -   427 Condition Technology module    -   428 scheduling module    -   429 workflow module    -   430 sub-request    -   432 sub-response    -   434 response    -   500 customer    -   502 internet    -   504 sales system    -   506 unique Identifier    -   507 interface    -   508 Fulfilment Coordination Engine    -   509 network    -   510 control program    -   511 database used for storage of sub-responses    -   512 database used for storage of the unique identifiers    -   513 XI Routing    -   514 request    -   515 interface    -   516 unique identifier    -   517 functions    -   518 rules module    -   520 purchasing system    -   522 manufacturing system    -   524 planning system    -   525 customizing and core data module    -   526 other internal or external system    -   527 Condition Technology module    -   528 scheduling module    -   529 workflow module    -   530 sub-request    -   532 sub-response    -   534 response    -   608 central data processing system    -   610 control program    -   612 database    -   613 main memory    -   614 request    -   618 rules module    -   619 interface    -   670 data    -   672 data

1. A data processing method for a customer request comprising: a)receiving a request for at least one item at a central data processingsystem; b) generating a plurality of sub-requests for a plurality ofpartner systems where each sub-request is assigned to an internal orexternal system by means of rules; c) generating a separate uniqueidentifier for each of the sub-requests; d) storing the uniqueidentifiers being assigned to the sub-requests, in a retrievable medium;e) sending the sub-requests with the unique identifiers to partnersystems; f) receiving back sub-responses at the central data processingsystem, said sub-responses having unique identifiers in association withthe unique identifiers of the request; g) generating a response based onassociation of the sub-responses with the original item; h) sending theresponse back to the customer data processing system.
 2. The method ofclaim 1, wherein said sending of the sub-requests to partner systemsfurther comprises at least one of: sending a sub-request for a partnersearch or a partner availability check at item level or: determining atleast one business system or an availability check for this system atitem level.
 3. The method of claim 2, wherein performing of the partnersearch is done with the use of functions.
 4. The method of claim 3,wherein the functions comprise standard functions, as well as functionsof customers and partners.
 5. The method of claim 2, wherein the partnersystem which received the request for availability check temporarilyreserves a requested resource that has been identified as available. 6.The method of claim 5, wherein the partner system deletes thereservation for the requested resources unless the central dataprocessing system sends a message if no acceptance is received from thecustomer within the predetermined time interval.
 7. The method of claim1, wherein the request comprises a plurality of items, the methodcomprising: performing b) to g) for each item.
 8. The method of claim 7,wherein the request comprising the plurality of items is processed in alooping mode.
 9. The method of claim 1, wherein the request for the atleast one item has a structure of an order-like document that comprises:a header section; at least one item; at least one schedule line per itemcomprising information regarding requested by the customer a deliverydate and a quantity.
 10. The method of claim 1, wherein b) includescriteria defined by the customer.
 11. The method of claim 1, furthercomprising the following operations conducted prior to h): comparing atleast one sub-response to the preferred choice specified by a customer;selecting a preferred choice from the group consisting of the at leastone sub-response.
 12. The method of claim 11, wherein the act ofselecting the preferred choice is based on the customer's preferences.13. The method of claim 11, wherein asynchronous communication means areused and the sub-responses are aggregated in the database until allsub-responses have been received.
 14. A central data processing systemfor processing of the customer request comprising: a) means forreceiving the request for at least one item at a central data processingsystem; b) means for generating a plurality of sub-requests forplurality of partners where each sub-request is assigned to an internalor external system by means of the rules; c) means for generating aseparate unique identifier for each of the sub-requests; d) means forstoring the unique identifiers being assigned to the sub-requests, in aretrievable medium; e) means for sending the sub-requests with theunique identifiers to partner systems; f) means for receiving backsub-responses at the central data processing system, said sub-responseshaving unique identifiers in association with the unique identifiers ofthe request; g) means for generating a response based on association ofthe sub-responses with the original item; h) means for sending theresponse back to the customer data processing system.
 15. The centraldata processing system of claim 14, wherein a central data processingsystem further comprises interfaces for communication between a salessystem, the purchasing system, the manufacturing system, the planningsystem and other internal or external systems.
 16. The system of claim14, further comprising asynchronous communication means to use databasetables for storage of the sub-responses.
 17. The system of claim 16,wherein the means of generating a response based on association of thesub-responses with the original item and sending the response back tothe customer data processing system, in case of the asynchronouscommunication, are applied only when all the requested sub-responses arecollected in the database.
 18. The system of claim 17, wherein theasynchronous communication means are to execute a query to determine ifall necessary sub-responses have been collected.
 19. A computer-readablestorage medium holding code to: a) receive a request for at least oneitem at a central data processing system; b) generate a plurality ofsub-requests for plurality of partners where each sub-request isassigned to an internal or external system by means of rules; c)generate a separate unique identifier for each of the sub-requests; d)store the unique identifiers being assigned to the sub-requests, in aretrievable medium; e) send the sub-requests with the unique identifiersto partner systems; f) receive back sub-responses at the central dataprocessing system, said sub-responses having unique identifiers inassociation with the unique identifiers of the request; g) generate aresponse based on association of the sub-responses with the originalitem; h) send the response back to the customer data processing system.20. A data processing system for processing a request, the dataprocessing system comprising: means for selecting an asynchronous or asynchronous communication mode for communication with partner computersystems, means for splitting the request into a set of sub-requests,synchronous communication means being adapted to send a first one of thesub-requests of the set of sub-requests to one of the partner computersystems, wait for the respective sub-response from the one of thepartner computer systems and send a second one of the sub-requests ofthe set of sub-requests to one of the partner computer systems after thesub-response has been received, wherein the sub-responses are stored ina random access memory, asynchronous communication means being adaptedto send the sub-requests in parallel to the partner computer systems,store respective sub-responses of the partner computer systems in adatabase on a non-volatile storage device, means for combining thesub-responses to generate a response to the request, means for sendingthe response.
 21. The data processing system of claim 20, wherein themeans for selecting the asynchronous or synchronous communication modecomprises a set of rules to be applied on the request.
 22. The dataprocessing system of claim 21, wherein the means for splitting therequest into a set of sub-requests uses the set of rules for thesplitting operation.
 23. The data processing system of claims 20,wherein the asynchronous communication means is to check the databasefor completeness for each incoming sub-response.
 24. The data processingsystem of claim 23, wherein the asynchronous communication means is toperform the check of the database by performing a database query usingthe sub-request and sub-response identifiers as keys.
 25. A method forprocessing a request comprising: selecting an asynchronous orsynchronous communication mode for communication with partner computersystems, splitting the request into a set of sub-requests, if thesynchronous communication mode has been selected: sending a first one ofthe sub-requests of the set to one of the partner computer systems,waiting for the respective sub-response from the one of the partnercomputer systems, sending a second one of the sub-requests of the set toa second one of the partner computer systems after the sub-response fromthe first one of the partner computer systems has been received, whereinthe sub-responses are stored in a random access memory, if theasynchronous communication mode has been selected: sending a pluralityof the sub-requests in parallel to partner computer systems, storingrespective sub-responses of the partner computer systems in a databaseon a non-volatile storage device, combining the sub-responses togenerate a response to the request, sending the response to therequestor.
 26. The data processing method of claim 25, wherein a set ofrules is used for selecting the asynchronous or the synchronouscommunication mode and for splitting the request into a set ofsub-requests.
 27. The data processing methods of claim 25, furthercomprising checking the asynchronous communication mode, checking thedatabase for completeness with each incoming sub-response.
 28. The dataprocessing method of claim 27, wherein a database query is performed foreach incoming sub-response, in order to determine whether allsub-responses for the request have been received.
 29. (canceled)